home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / sdkdigv8.zip / SDKV8N19.TXT < prev    next >
Text File  |  1994-01-21  |  9KB  |  211 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Programmer's Digest     Fri, 21 Jan 94  4:05         Volume 8: Issue  19  
  5.  
  6. Today's Topics:
  7.                                 _HELP_
  8.                     GUS Programmer's Digest V8 #17
  9.                         Patches and envelopes
  10.                         UltraStartVoice -mode
  11.  
  12. Standard Info:
  13.     - Meta-info about the GUS can be found at the end of the Digest.
  14.     - Before you ask a question, please READ THE FAQ.
  15.  
  16. ----------------------------------------------------------------------
  17.  
  18. Date: Fri, 21 Jan 1994 10:18:13 +1030 (CST)
  19. From: Gavin <SCARMAN@hfrd.dsto.gov.au>
  20. Subject: _HELP_
  21.  
  22. OK, I give up. I can't even get the bloody example that came with sdk2.01 to 
  23. play a real voice. This is what I did...
  24.  
  25. Using Patch.exe:
  26. 1/ load woodflut.pat
  27. 2/ noted the loop points. these appear to be half the value of what's in the 
  28. patch header because it's a 16 bit patch (?).
  29. 3/ saved the raw info as woodflut.raw
  30. 4/ ran playfile loaded woodflut.raw /set volume to 256
  31. 5/ played the file as 16bit/unsigned/mono/22050 and it sounds like a woodflut.
  32. 6/ ran example.exe and loaded woodflut.raw/unsigned/16bit/3856bytes
  33. 7/ note on: start0/loopstart3740/loopend3826/16bit/uni-looping
  34. 8/ result = garbage. sounds very much like random bytes.
  35. 9/ beats me what I'm doing wrong.
  36.  
  37. PLEASE will someone give me an example of loading and playing a patch using the 
  38. SDK.
  39.  
  40. ------------------------------
  41.  
  42. Date: Thu, 20 Jan 94 21:46:50 MST
  43. From: "Shawn T. Rutledge" <rutledge@enuxhb.eas.asu.edu>
  44. Subject: Re: GUS Programmer's Digest V8 #17
  45.  
  46. > From: bpage@infi.net (Bob Page)
  47. > Subject: Re: programming Voice recognition for GUS
  48. > 
  49. > If anyone is interested, I have posted on EPAS the Creative Labs Voice
  50. > Assist demo that came with my Borland C++ 4.0 CD upgrade.  It includes
  51. > source (C & C++) examples, API info and other "goodies".
  52. > 
  53. > -- 
  54. > --- Bob Page (bpage@infi.net) 
  55.  
  56. Are you implying that this can be used with the GUS?  I got a friend's
  57. soundblaster version, and it wouldn't work with the GUS.
  58.  
  59. ------------------------------
  60.  
  61. Date: Thu, 20 Jan 1994 22:42:24 -0500 (EST)
  62. From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
  63. Subject: Patches and envelopes
  64.  
  65. Jason, 
  66.  
  67. Mail to you bounced, so I'm forwarding my letter to you to the
  68. SDK digest since you seem to be receiving it okay.
  69.  
  70.    ----- Recipients of this delivery -----
  71. Jason William Whiteman <jww9624@tamsun.tamu.edu> (bounced)
  72.  
  73. [ ^^^ That was the address and userid I sent to.]
  74.  
  75. On Thu, 20 Jan 1994, Jason William Whiteman wrote:
  76.  
  77. > 
  78. > Phat,
  79. > 
  80. >     I appreciate your concern for clarifying the patch format.  I would
  81. > have liked to see Forte acknowledge the need for fractional start/stop points
  82. > (voice) in the SDK; but you can't have everything [for free].
  83. >     Now, a little clarification is needed:
  84. > 
  85. > Forwarded message:
  86. > > Since the GUS' volume is log instead of linear, with a zero volume setting
  87. > > of zero and not negative infinity, I'm not sure how we'd go about attenuating
  88. > > the envelope offsets.  Do we substract some x from the offsets based on the
  89. > > channel volume?  I think this would be the way it's done for a true log scale
  90. > > (i.e. one that goes to negative infinity for zero volume).  For the GUS,
  91. > > it's probably best to treat everything linearly, and just use the following
  92. > > formula:
  93. > > 
  94. > >   linoffset = chan_vol/127 * expression/127 * absoffset
  95. > >   logoffset = log(linoffset + 1)/log(128) * K
  96. > > 
  97. > 
  98. >     Ok, a few variables were introduced here:
  99. > 
  100. > linoffset  : intermediate value for the linear offset value
  101. > chan_vol   : the current voice's volume
  102.  
  103. The channel volume is controlled by MIDI controller 7, and can be from
  104. 0 to 127.
  105.  
  106. > expression : I don't know what exactly the expression is to represent. I
  107. >              suppose it is some sort of MIDI data.  What is the default
  108. >              expression value?  That is, if I were to keep expression
  109. >              constant, what should it be kept at (127?)
  110.  
  111. The expression is set by controller 11.  It's another "knob" you can
  112. "twiddle" to adjust the volume.  I think it's usually used to modulate
  113. the volume of a voice as it's playing (eg. during a crescendo), whereas
  114. the channel volume is usually set once at the start and left alone.
  115.  
  116. If you're not aware, MIDI messages can be sent on one of 16 channels.
  117. Expression and channel volume can be set independently for each 
  118. channel.  If, for example, the expression for channel 1 is set to 110,
  119. and its volume set to 120, an envelope offset would be scaled as 
  120. follows:
  121.  
  122.    linoffset = 110/127 * 120/127 * absoffset
  123.  
  124. Well, I shouldn't sound so authorative, since that's only how I _think_
  125. the envelopes are scaled after fooling around with Forte's drivers.
  126.  
  127. > absoffset  : the envelope offset value Envelope_Offset[x]
  128. > K          : 1000 (?)
  129.  
  130. K would be 4096, the GUS' maximum hardware volume setting.
  131.  
  132. ------------------------------
  133.  
  134. Date: Thu, 20 Jan 94 10:20:59 EST
  135. From: support@fortech.com (Technical Support)
  136. Subject: Re: UltraStartVoice -mode
  137.  
  138. > This mode byte has me stumped. I've loaded the raw data into the GUS from a 
  139. > patch (woodflut) after having read the headers.
  140.  
  141. > If you read the example.c from sdk2.01:
  142.  > it ORs the mode (control) byte with 0x08 ie. bit3 for uni-directional looping 
  143. > but in the patch.h it says bit3 is bi-directional looping???
  144.  
  145. > But me problem is if I UltraStartVoice with the control/mode byte set to 0x08 I 
  146. > get a sound (which may possibly be a woodflute), if I use the mode byte read 
  147. > from the patch 0x67 then I get no sound at all. To me 0x67 seems to make more 
  148. > sense than 0x08 but it doesn't work! To get the mode byte I'm just fread'ing the 
  149. > structures in patch.h. 
  150.  
  151. The difference in the mode bytes is that the one used in UltraStartVoice
  152. is actually  what gets written to the hardware register for the voice. The
  153. mode in the patch is interpretted by software and not written directly
  154. to the hardware. The program will look at the mode in the patch and set
  155. the appropriate bits in the mode that gets written to the hardware. Some
  156. of the bits in the mode in the patch are of no interest to the hardware.
  157.  
  158. Hope this helps.
  159.  
  160. Forte Tech Support
  161.  
  162. ------------------------------
  163.  
  164. From: (null)
  165.  
  166. > I think you gave an answer in terms of implementing a MIDI engine.
  167. > Although a MIDI engine would be a nice place to go with implementing the
  168. > patches, at this point I'm just working on starting at a volume and
  169. > playing the envelope correctly.  I am not very familiar with expression
  170. > (what it means, or the upper limit of the expression value).  Nor do I
  171. > know the upper limit of a chan_vol.  I'd like to keep everything at the 
  172. > GUS hardware level before adapting to the MIDI standard.  That is, an
  173. > upper limit for a volume = 4095 (logarithmic).  I was under the impression
  174. > that the patch format should map directly to the GUS (and not MIDI).  That
  175. > is, volumes/envelopes/etc should all have the GUS's logarithmic nature
  176. > in mind.
  177.  
  178. It's hard to get intuitive results using the GUS' native logarithmic
  179. volumes.  I find it more convenient to think of volumes linearly,
  180. with 2 twice as loud as 1, and 64 twice as loud as 32, etc.  That makes
  181. the process of shaping the overall volume rather obvious:  just 
  182. multiply the volume factors together.  Once you have the final scaled
  183. linear volume, it's a simple step to convert it to the GUS' log volume.
  184.  
  185. I'd like to know what your thoughts are on all this. 
  186.  
  187. Phat.
  188.  
  189. ------------------------------
  190.  
  191. End of GUS Programmer's Digest V8 #19
  192. *************************************
  193.  
  194. To post to tomorrow's digest:                    <gus-sdk@dsd.es.com>
  195. To (un)subscribe or get help:            <gus-sdk-request@dsd.es.com>
  196. To contact a human (last resort):          <gus-sdk-owner@dsd.es.com>
  197.  
  198. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  199.                      wuarchive.wustl.edu            /systems/ibmpc/ultrasound
  200.                      archive.orst.edu                    /pub/packages/gravis
  201.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  202.                      nctuccca.edu.tw                           /PC/ultrasound
  203. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  204.  
  205. Hints:
  206.       - Get the FAQ from the FTP sites or the request server.
  207.       - Mail to <gus-sdk-request@dsd.es.com> for info about other GUS
  208.     related mailing lists (general use, musician's, etc.).
  209.  
  210.  
  211.